Automatic Retransmission requests (ARQs) are utilized in numerous applications, especially in the field of telecommunications. Generally, designs using ARQs store transmitted data strings temporarily in memory for use in the event that a retransmission request is received (i.e., when a decoder fails to correctly decode the received data string), creating a temporary buffer of transmitted data. If a retransmission request is received, a data string is re-transmitted. Once the retransmitted data string is received, the decoder attempts once again to decode the string. Only when a decoder successfully decodes a string will the next data string be received.
Prior art designs using ARQ utilize a “stop-and-wait” functionality. Once a transmission is sent, the transmitted data string is held in a buffer (or small memory block) in the transmitter until either an acknowledgement (ACK) or not-acknowledgement (NACK) signal is received from the decoder. If an ACK is received, the next string of data is sent to the recipient. If a NACK is received, a retransmission request is sent to the original transmitter.
In order to overcome delays between reception of a block and its retransmission (which can be due to processing latencies, e.g., decode and transmission of an acknowledgement/not-acknowledgement (ACK/NACK) signal), many implementations, including the well known 3GPP standards, support multiple, or parallel, stop-and-wait ARQ processes. 3GPP (the 3rd Generation Partnership Project) is a collaboration agreement established in December 1998 that brought together a number of telecommunications standards and described several standards for use with systems employing ARQ. One such standard is the parallel stop-and-wait ARQ process. Parallel stop-and-wait processes have the effect of increasing the throughput by utilizing what would otherwise be dead time between transmission of the data and reception of the ACK/NACK signal. Essentially, a parallel stop-and-wait ARQ process utilizes multiple stop-and-wait processes running simultaneously. Once a first data string is sent, additional data strings are sent until the ACK/NACK is received for the first string. If a NACK is received, the first data string is loaded from memory and retransmitted. If an ACK is received, the new data string is received that overwrites the first data string in memory.
Unfortunately, when parallel stop-and-wait ARQ processes are used, the receiver must store up to n strings of data, where n is the number of parallel ARQ processes that can be supported, requiring a significant amount of additional memory (which increases the cost of the receiver). Compared to a single stop-and-wait process, a parallel stop-and-wait process requires a memory block n times larger.
Any communication system implementing a stop-and-wait ARQ process, whether single or parallel, has large memory requirements for storage of received data between retransmissions, which consumes significant chip area. While systems using single stop-and-wait ARQ systems do not require as large a memory block as those using parallel ARQ, they inefficiently use the transmission channel and, subsequently, processing time is lost as only one data transmission is processed at a time.
Improvements in system performance can be achieved by performing “chase combining” in the receiver. Chase combining is the combining of a transmission and its subsequent retransmissions in the receiver and passing the combined transmissions to the decoder. This achieves improved performance because the combination of multiple transmissions is more accurate than any of the single transmissions on their own. Chase combining, however, requires significant memory as the receiver must store soft information (usually in the form of log-likelihood ratios) rather than hard samples such that samples between transmissions can be combined with an appropriate weight. In ARQ systems employing chase combining, a receiver converts each bit of a received transmission to a log-likelihood ratio (LLR) bit (i.e., a soft sample of the data string). Each conversion is based upon the likelihood of that bit having been transmitted correctly. Once the transmitted data string is converted, the data string is then stored in memory. Once a retransmission request is received, the stored data string is loaded and combined with the re-received data string. Since the stored data string has been converted to an LLR, each bit is weighted appropriately based upon the likelihood of it having been correct when originally received.
One of the standards of 3GPP describes an implementation of a variant of ARQ known as hybrid-ARQ or HARQ. A major difference between a traditional stop-and-wait ARQ and HARQ is that in HARQ a different subset of coded data may be sent on each transmission, and subsequent retransmission. Sending different subsets of the coded data on retransmissions is also known as incremental redundancy. In HARQ, a data string is encoded along with an error correction code. HARQ results in better performance but increases the implementation complexity. Whether traditional ARQ or HARQ is implemented, received data strings should be stored between transmissions such that if a transmission failure occurs a stored data string can be combined with the next transmission of a data string to improve the probability of making a successful decode.
State of the art technology utilizing parallel stop-and-wait ARQ and chase combining, together with the HARQ variation, leads to superior system performance, but requires a very large memory in the receiver (many-times larger than the number of bits in a single transmission).
What is needed is a way to reduce the size of the onboard memory utilized in an ARQ system, thereby resulting in reduced silicon cost and reduced power consumption, particularly for battery powered consumer devices such as cellular telephones.